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© Datenverarbeitungsgestutztes elektronisches Steuerungssystem, insbesorvdere fur ein Kraftfahrzeug 

© Die Erfindung bezieht sich auf ein Steuerungssystem 
mit einem Anwendungsfunktionen ausfuhrenden Steuer- 
gerateverbund mit mehreren, verteilt angeordneten Steu- 
ergeraten und einem diese verbindenden Datenubertra- 
gungsnetzwerk. 

Erfindungsgemaft sind die Anwendungsfunktionen in 
Form einer Client/Server-Architektur j n dem Steuergera- 
teverbund implementiert. Dies ermoglicht die Durchfuh- 
rung von Anwendungsfunktionen in Echtzeit mittels eines 
flexiblen, standardisierten und offenen Systems, mit dem 
Anderungen und/oder Erganzungen von Anwendungs- 
funktionen mit relativ geringem Aufwand realisierbar 
sind. 

Verwendung z. B. als Steuerungssystem in einem Kraft- 
fahrzeug. 
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Beschreibung 

Die Erfindung bezieht sich auf ein datenverarbeitungsge- 
stiitztes elektronisches Steuerungssystem mit einem An- 
wendungsfunktionen ausfuhrenden Steuergerateverbund 5 
mit mehreren, verteilt angeordneten Steuergeraten und ei- 
nem diese verbindenden Datehubertragungsnetzwerk. Der 
Begriff Steuerungssystem ist hierbei in seinem weiteren, 
auch Regelungssysteme umfassenden Sinne zu verstehen. 

Derartige Steuerungssysteme werden beispielweise in 10 
Kraftfahrzeugen eingesetzt, um dort die fahrzeugtypischen 
Steuerungsfunktionen auszufuhren. In herkommlichen Sy- 
stemen werden die Steuergerate jeweils spezifisch fur eine 
oder mehrere Anwendungsfunktionen ausgelegt. Die Imple- 
mentierung einer neuen Fahrzeugfunktion erfordert den Ent- 15 
wurf eines zugehorigen neuen Steuergerates und dessen 
Einbau im Fahrzeug zusammen mit einer neuen Sensor- und 
Aktuatorkonfiguration. Zwar sind die Steuergerate in mo- 
derneren Konfigurationen z. B. uber einen CAN-Bus ver- 
netzt, jedoch existieren keine expliziten Schnittstellen fur 20 
den Zu griff; auf einzelne Funktiensteile, so dafi die jeweilige 
Anwendungsfunktion aus Sicht des Steuergerates nur als 
Ganzes in Erscheinung tritt. Zur Realisierung von neuen, 
auf existierende Funktionen aufgebauten, sogenannten re- 
kombinierten Funktionen mussen diese folglich mit hohem 25 
Aufwand von Hand an existierende Funktionen angeschlos- 
sen werden, z. B. durch Definition oder Anderung entspre- 
chender CAN-Botschaften. In ungiinstigen Fallen macht 
dies fur die Hinzufugung einer einzelnen neuen Funktion 
die Anderung aller anderen Steuergerate notig. Dies fuhrt 30 
zusammen mit dem Trend zu immer mehr elektronisch rea- 
lisierten Funktionen im Kraftfahrzeug und deren zunehmen- 
der Kopplung untereinander zu einer stark anwachsenden 
Komplexitat und zu entsprechenden Schwierigkeiten bei der 
Entwicklung und Beherrschung der gesamten Fahrzeuge- 35 
lektronik sowie zu einem steigenden Bedarf an Rechenlei- 
stung und Speicherumfang. Zudem ergibt sich durch die 
steigende Komplexitat bei gleichzeitig immer mehr Baurei- 
hen und kiirzeren Entwicklungszeiten fur dieselben der Be- 
darf, Komponenten vermehrt baureihenubergreifend wie- 40 
derverwenden zu konnen. 

Von reinen Datenverarbeitungssystemen, z. B. zur Biiro- 
kommunikation und in Grofirechenanlagen, mit verteilten 
Rechnerkapazitaten ist es bekannt, sogenannte Client/Ser- 
ver-Architekturen vorzusehen, um einen jeweiligen Dienst 45 
von einem hierauf ausgelegten Server fur diesen Dienst auf- 
rufende Clients zentralisiert zu erbringen. Bei diesen Syste- 
men ist im allgemeinen keine Echtzeitverarbeitung gegeben. 

Der Erfindung liegt als technisches Problem die Bereit- 
stellung eines insbesondere auch fur Kraftfahrzeuge an- 50 
wendbaren Steuerungssystems der eingangs genannten Art 
zugrunde, das sich zurDurchfuhrung der Anwendungsfunk- 
tionen in Echtzeit und auch mit relativ knappen Rechenka- 
pazitaten eignet und moglichst flexibel, standardisiert und 
offen ausgelegt ist, um Anderungen und/oder Erganzungen, 55 
insbesondere hinsichtlich Implementierung neuer und/oder 
Modifikationen bestehender Anwendungsfunktionen, mit 
vergleichweise geringem Aufwand realisieren zu konnen. 

Die Erfindung lost dieses Problem durch die Bereitstel- 
lung eines Steuerungssystems mit den Merkmalen des An- 60 
spruchs 1. Bei diesem datenverarbeitungsgestiitzten elektro- 
nischen Steuerungssystem sind die vom System durchzu- 
fuhrenden Anwendungsfunktionen in Form einer Client/ 
Server-Architektur in den Steuergerateverbund implemen- 
tiert. Die Client/Server-Architektur wird vorliegend in ei- 65 
nem sogenannten Embedded- System verwendet, d. h. einem 
System, in welchem die elektronische Datenverarbeitungs- 
funktionalitat in ein ubergeordnetes System, wie z. B. eine 
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Fahrzeugfunktionen ausfuhrende Fahrzeugelektronik, die- 
ses stiitzend eingebettet ist und dem Anwender nicht direkt 
in Erscheinung tritt: Durch die Ubertragung der aus Daten- 
verarbeitungssystemen bekannten Client/Server-Architek- 
tur auf das vorliegende Steuerungssystem wird ein Modell ! 
zur Strukturierung verteilter Anwendungen bereitgestellt, 
das besonders gut zur Beschreibung ereignisorientierter Sy- 
steme geeignet ist, wobei im Unterschied zu konventionel- 
len Systemen die Schnittstellen zwischen Client- und Ser- j 
ver-Prozessen primar an Diensten und nicht an Daten orien- ; 
tiert sind. Mit dem vorliegenden System konnen die Anwen- | 
dungsfunktionen hardwareunabhangig entwickelt und rela- ! 
tiv einfach zwecks Erzeugung neuer, hoherwertiger Anwen- j 
dungsfunktionen rekombiniert werden. Im Rahmen der ! 
Client/Server-Architektur werden die Anwendungsfunktio- j 
nen beschrieben, die uber definierte Anwendungsprotokoll- \ 
Schnittstellen miteinander kommunizieren, wozu zum Ent- 
wurfszeitpunkt noch keine Aussage uber die Art der physi- \ 
kalischen Kommunikation gemacht wird. Damit lassen sich 
durch das erfindungsgemaBe Steuerungssystem Anwen- | 
dungsfunktionen in Echtzeit durchfuhren und. vergleichs- i 
weise einfach in verschiedene Systemauslegungen, z. B. bei ! 
verschiedenen Fahrzeugbaureihen, implementieren. Die | 
elektronische Infrastruktur des Steuerungssystems besitzt 
durch die Verwendung des Client/Server-Architekturmo- • 
dells eine flexible, standardisierte und offene Basis und eig- 
net sich insbesondere auch fur Systeme mit vergleichsweise ; 
geringen Rechenleistungsressourcen und statischer Soft- • 
ware-Konfiguration. ! 

Bei einem nach Anspruch 2 weitergebildeten Steuerungs- ! 
system beinhaltet die Client/Server-Architektur fur eine je- ! 
weilige Anwendungsfunktion eine zwischen einer Client- 
ebene und einer Serverebene liegende Funktionsmonitor- 
ebene, die den globalen Zustand der Anwendungsfunktion 
verwaltet und somit als deren zentrale Schaltstelle oder Ge- 
dachtnis fungiert. In weiterer Ausgestaltung dieser Struktu- 
rierung sind nach Anspruch 3 eine oder mehrere dieser drei 
Ebenen in spezieller Weise weiter strukturiert. Die Client- j 
ebene kann hierbei aus Requestoren als Quellen von Dienst- ! 
anforderungen und nachgeschalteten primaren Clients be- \ 
stehen, wahrend analog dazu die Serverebene aus primaren ! 
Servem und nachgeschalteten Fulfillern aufgebaut sein 
kann. Ein primarer Chent und der zugehorige Requestor 
bzw. ein primarer Server und der zugehorige Fulflller wer- 
den stets auf demselben Steuergerat angeordnet. Die Moni- 
torebene beinhaltet einen mit den primaren Clients kommu- 
nizierenden Funktionsmonitor, der den globalen Zustand der 5 
Anwendungsfunktion verwaltet, und von diesem abhangige 
Monitore fur die Verwaltung von Teilfunktionen. '■■ 

Der Funktionsentwurf basiert auf einer Menge von defi- 
nierten Designelementen wie Methoden und Protokolle, ! 
Service- Access-Points und Service- Access-Point-Inter- ! 
faces, Ports und Portinterfaces, Verbindungen, Prozessen, j 
Frames und Firmwareprozessen. In Weiterbildung der Erfin- i 
dung nach Anspruch 4 sind die Service-Access-Points cha- 
rakteristischerweise so ausgelegt, daB sie Schnittstellen von \ 
Anwendungsprozessen zur Schicht 7 des ISO/QSI-Refe- \ 
renzmodells bilden und je ein Protokoll in Client- und in ! 
Serverrolle enthalten. In einer Ausgestaltung der Erfindung ; 
nach Anspruch 5 sind die Ports als Ankerpunkte fur bidirek- j 
tionale Ctient/Server-Kommunikations verbindungen zur j 
Implementierungszeit ausgelegt und stellen eine horizontale j 
Kommunikations-Schnittstelle auf der Schicht 7 des ISO/ j 
OSI-Referenzmodells dar. ; 

In weiterer Ausgestaltung der Erfindung nach Anspruch 6 ! 
sind die Prozesse als Designelemente, welche die eigentli- i 
che Anwendungssoftware beinhalten, in spezieller Weise \ 
aus einer auBeren Schnittstelle, einer inneren Struktur und ; 
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einem spezifischen Verhalten auf eingehende Dienstanfor- 
derungen aufgebaut. 

In Weiterbildung der Erfindung nach Anspruch 7 besitzt 
das Steuerungssystem ein echtzeitfahiges Multitasking-Be- 
triebssystem in den Steuergeraten, und die Client/Server- 5 
Prozesse sind so implement! ert, daB sie ohne direkten Hard- 
warezugriff nur die Dienste des Betriebssystems und einer 
zugehorigen Kommunikationsschicht nutzen, die auf der so- 
genannten Remote-Procedure-Call (RPC)-Technik basiert, 
wie sie der Art nach von Datenverarbeitungssysternen mit 10 
Client/Server-Architektur fur eine solche Kommunikation 
zwischen Client/Server- Prozessen bekannt ist. 

In weiterer Ausgestaltung der Erfindung ist nach An- 
spruch 8 vorgesehen, daB in einer entsprechenden RPC-Bi- 
bliothek ein volistandiger Server-Code enthalten ist, der pro 15 
Steuergerat genau einmal eingebunden ist und von alien 
Client- und Server-Prozessen abgearbeitet wird. Dies mini- 
miert den Ressourcenbedarf und maximiert gleichzeitig die 
Wiederverwendungsfahigkeit. 

In weiterer Ausgestaltung der Erfindung erfolgt die Initia- 20 
lisierung des Servers gemaB Anspruch 9 in vier speziellen 
Phasen. 

GemaB einer Weiterbildung der Erfindung nach Anspruch 
10 ist der Remote-Procedure- Call (RPC) als synchroner 
RPC, asynchroner RPC oder Oneway-RPC realisiert. 25 

In Weiterbildung der Erfindung nach Anspruch 11 ist eine 
minimale bzw. ressourcenoptimierte Pro tokollimplemen tie- 
rung vorgesehen, die jeder Methode eine identifizierende 
Dienstnummer zuweist und bei der in den Nutzdaten der 
versendeten Nachrichten sowohl der Nachrichtentyp als 30 
auch die Dienstnummer und die ubergebenden Daten co- 
diert sind. Das so implementierte Protokoll ist z. B. auf ei- 
nem CAN-Bus verwendbar. 

Vorteilhafte Ausfuhrungsformen der Erfindung sind in 
den Zeichnungen dargesteilt und werden nachfolgend be- 35 
schrieben. Hierbei zeigen: 

Fig. 1 eine ausschnittweise Blockdiagrarnm-Darstellung 
eines Steuergerateverbundes eines Kraftfahrzeug-Steue- 
rungssystems, 

Fig. 2 eine Blockdiagrarnm-Darstellung der Entwurfs- 40 
struktur einer im Steuerungssystem von Fig. 1 implemen- 
tierten Client/Server-Architektur, 

Fig. 3 eine Darstellung des graphischen Erscheinungsbil- 
des der inneren Struktur einer ProzeBklasse fur die Client/ 
Server- Architektur, 45 

Fig. 4 eine graphische Darstellung der Einbettung eines 
endlichen Automaten in eine ProzeBklasse der Client/Ser- 
ver-Architektur, 

Fig. 5 eine graphische Darstellung des Client/Server-De- 
signs am Beispiel einer Ruckfahrscheinwerfer-Anwen- 50 
dungsfunktion, 

Fig. 6 ein Blockdiagramm der fur die Client/Server-Ar- 
chitektur verwendeten Steuergerate-Software, 

Fig. 7 eine blockdiagrammatische Darstellung der Pro- 
zeBkommunikation der Client/Server-Architektur mittels 55 
Protokollen auf Anwendungsschichtebene, 

Fig. 8 ein Blockdiagramm eines prinzipielien ORPC-Ab- 
laufs in der Client/Server-Architektur, 

Fig. 9 ein FluBdiagramm des Server- Arbeitsablaufs in der 
Client/Server-Architektur, 60 

Fig. 10 ein FluBdiagramm des Ablaufs einer Server-In- 
itialisierungsphase, 

Fig. 11 ein FluBdiagramm einer synchronen RPC-Imple- 
rnentierung, 

Fig. 12 ein FluBdiagramm einer Oneway-RPC-Imple- 65 
mentierung und 

Fig. 13 eine schematische Blockdiagrarnm-Darstellung 
des implementierten Protokolls der Client/Server- Arc hitek- 
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tur. 

Fig. 1 zeigt ausschnittweise und blockdiagrammatisch 
mehrere, verteilt angeordnete Steuergerate la, lb, lc und 
ein diese verbindendes Daten iibertragungsnetzwerk mit ei- 
nem Datenbus 2, z. B. einem CAN-Bus, eines Steuergerate- 
verbunds zur Ausfuhrung von Anwendungsfunktionen in ei- 
nem Kraftfahrzeug. In dem Steuergerateverbund dieses 
Steuerungssy stems sind die Anwendungsfunktionen in 
Form einer Client/Server-Architektur (CSA) implementiert, 
die dafur sorgt, daB alle Systemschnittstellen beschrieben 
sind und nur iiber selbige mit den Objekten kommuniziert 
wird und Daten ausgetauscht werden. Soweit diese Client/ 
Server- Architektur in ihrer Struktur und ihren Komponenten 
den herkommlichen Client/Server- Architekturen entspricht, 
wird darauf im folgenden nicht naher eingegangen, sondern 
auf die betreffende Literatur verwiesen und die entspre- 
chende Terminologie verwendet. Durch diese Architektur 
wird eine Portability der Software zwischen verschiedenen 
Hardware-Plattformen erreicht. Die Nutzung eines von her- 
kommlichen objektorientierten Methoden bekannten Con- 
struction-from-Parts-Ansatzes kann dafur sorgen, daB sich. 
einmal spezifizierte, implementierte und getestete Pro- 
grammteile immer wieder verwenden lassen. Weiter wird 
durch Realisierung der Kommunikation auf Basis eines Re- 
mote-Procedure-Calls (RPC) gewahrleistet, daB einzelne 
Prozesse beliebig im Steuergeratenetzwerk verteilt werden 
konnen, ohne die Funktionsentwurfe oder die implemen- 
tierte Software manuell anpassen zu miissen. Fig. 1 veran- 
schaulicht beispielhaft, wie auf diese Weise eine Applika- 
tion aus einem Client-ProzeB 3, einem Funktionsmonitor 3b 
und einem Server-ProzeB 4a, 4b auf den Steuergeraten la, 
lb, lc verteilt werden kann. Ein weiterer Server 4a gehort 
nicht zu dieser Client/Server-Kette. Der Funktionsmonitor 
3b fungiert sowohl als Server (gegenuber Client 3) wie auch 
als Client (gegenuber Server 4b). 

Fig. 2 zeigt im Blockdiagramm den Systementwurf einer 
jeweiligen Anwendungsfunktion im Rahmen der erfin- 
dungsgemaB verwendeten Client/Server-Architektur. Ge- 
maB diesem Systementwurf ist die jeweilige Anwendungs- 
funktion in eine Clientebene 5, eine Serverebene 6 und eine 
zwischenliegende Funktionsmonitorebene 7 strukturiert. 
Die Clientebene 5 beinhaltet einen oder mehrere prirnare 
Clients 5a mit vorgeschaltetem Requestor 5b. Die Requesto- 
ren 5b reprasentieren ereignisauslosende Hardwareeinhei- 
ten, wie Sensoren, und die zugehorige Steuergerate-Firm- 
ware. Sie stellen die Quellen von Dienstanforderungen der 
modellierten Anwendungsfunktion dar. Die primaren 
Clients 5a verwalten die Requestoren, nehmen deren 
Dienstanforderungen entgegen und setzen gegebenenfalls 
weitere Auftrage an die Funktionsmonitorebene 7 ab. Die 
primaren Clients 5a werden stets auf demselben Steuergerat 
wie der zugehorige Requestor 5b angesiedelt und eriauben 
es, die Dienstanforderung auch iiber Kommunikationsme- 
dien weiterzuleiten, wozu der Requestor 5b nicht ausgelegt 
ist. Die Funktionsmonitorebene 7 beinhaltet fur jede An- 
wendungsfunktion einen Funktionsmonitor 7a, der die 
Dienstanforderungen von primaren Clients 5a und gegebe- 
nenfalls von Funktionsmonitoren ubergeordneter Anwen- 
dungsfunktionen entgegennimrnt und bearbeitet. Er kann 
dazu weitere Dienste von ihm untergeordneten Monitoren 
oder primaren Servern in Anspruch nehmen. Der Funktions- 
monitor 7a verwaltet den globalen Zustand der Anwen- 
dungsfunktion und bildet damit deren zentrale Schaltstelle 
und Gedachtnis. Dem Funktionsmonitor 7a sind innerhalb 
der Funktionsmonitorebene 7 gegebenenfalls ein oder meh- 
rere Monitore 7b nachgeschaltet, die Teilfunktionen verwal- 
ten und sich vom Funktionsmonitor 7a dadurch unterschei- 
den, daB sie nicht direkt mit primaren Clients 5a und Funk- 
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tionsmonitoren 7a anderer Anwendungsfunktionen kommu- 
nizieren. Die Serverebene 6 beinhaltet einen oder mehrere 
primare Server 6a und einen jeweils zugehorigen Fulfiller 
6b. Die Fulfiller 6b reprasentieren ausfuhrende Hardware- 
Einheiten, wie Aktuatoren, und die zugehdrige Steuerge- 5 
rate- Firm ware. Sie stellen die Senken von Dienstanforde- 
rungen der modellierten Anwendungsfunktion dan Die pri- 
maren Server 6a verwalten die Fulfiller 6b und beauftragen 
diese mit der Ausfuhrung von Diensten. Sie sind stets auf 
demselben Steuergerat wie der zugehdrige Fulfiller 6b ange- 10 
siedelt und erlauben es, Dienstanforderungen von entfernten 
Monitoren 7b entgegenzunehmen, worauf die Fulfiller 6b 
nicht ausgelegt sind. 

Die Pfeile in Fig. 2 reprasentieren Client/Server-Bezie- 
hungen, wobei der Pfeil vom Client zum jeweiligen Server 15 
verlauft und fur ein bestimmtes Anwendungsprotokoll steht. 
Normalerweise verhalt sich ein Server dabei synchron zu 
den aufrufenden Clients. Die Richtung der Pfeile deutet auf 
diese Betriebsart hin. In Ausnahmesituationen ist es jedoch 
auch moglich, daB ein Server 6a asynchron Informadonen 20 
an einen oder mehrere seiner Clients 5a sendet. In diesem 
Ausnahmebetrieb findet eine Umkehr der jeweiligen Rollen 
statt, fur die ein eigenes Protokoll zu vereinbaren ist. 

Der Funktionsentwurf fur die Client/Server- Architektur 
mit der in Fig. 2 dargestellten Anwendungs-Entwurfsstruk- 25 
tur basiert auf einer Menge von hierfiir geeignet definierten 
Designelementen. Die Entwurfsmethodik sieht dabei eine 
spezielle graphische Notation fiir die Designelemente vor, 
wodurch sie von graphischen Entwurfswerkzeugen unter- 
stiitzt werden kann, was die Lesbarkeit von Entwiirfen so- 30 
wie das Erlernen der Methodik verglichen mit rein textuel- 
len Notationen erleichtert. Speziell sind als Designelemente 
den Requestoren 5b eine Sensor- Firm ware, den Fulfillern 6b 
eine Aktuator-Firmware, den Client/Server-Beziehungen 
Verbindungen und den primaren Clients 5a, den Funktions- 35 
monitoren 7a, den Monitoren 7b und den primaren Servern 
6a ProzeBklassen zugeordnet. 

Allgemein sind als Designelemente Methoden und Proto- 
kolle, Service- Access-Points (SAP) und Service- Access- 
Point-Interfaces (SAPEF), Ports und Port-Interfaces (Por- 40 
tIF), Verbindungen, Datenelemente, Prozesse, Frames und 
Firmware-Prozesse vorgesehen. Methoden stellen in diesem 
Zusarnmenhang Funktionalitat dar, die eine ProzeBklasse 
anderen ProzeBklassen als Dienste an den SAPs in Server- 
rolle zur VerfUgung stellt. Andererseits kann dieselbe Pro- 45 
zeBklasse an SAPs in Clientenrolle Dienste anfordern, die 
von anderen ProzeBklassen als Methoden an SAPs in Ser- 
verrolle angeboten werden. Methoden haben wie herkomm- 
liche Funktionsaufrufe eine Typ und Argumente, wobei der 
Typ angibt, welches Datenformat der Ruckgabewert der 50 
Methode hat. Fur die Anwendung ist es transparent, ob die 
Dienstanforderung als Remote-Procedure- Call mittels Sen- 
den/Empfangen uber ein externes physikalisches Kommuni- 
kationsmedium, mittels InterprozeBkommunikation oder 
mittels Eventmechanismus vom Client zum Server kommu- 55 
niziert wird. Protokolle dienen der Aggregierung von Me- 
thoden. Zu diesem Zweck beinhalten sie eine Liste von Me- 
thoden, die aus Sicht des Anwendungsentwicklers eine 
funktionale Einheit darstellen. Des weiteren konnen Proto- 
kolle hierarchisch strukturiert werden, d. h. es kann eine 60 
Hierarchie von Protokollen dergestalt aufgebaut werden, 
daB ausgehend von einem Null-Protokoll, das keine Metho- 
den enthalt, eine Baumstruktur von Protokollen entsteht, in 
der ein neu hinzugefugtes Protokoll alle Methoden des zur 
Wurzel des Baumes hin nachstliegenden Protokolles erbt 65 
und gegebenenfalls weitere hinzufugt. 

Die SAPs sind die Schnittstellen von Anwendungsprozes- 
sen zur Schicht 7 des ISO/OSI-Referenzmodells und bein- 



halten je ein Protokoll in Client- und in Serverrolle. Die 
SAPs haben eine Vorzugsrichtung, die entweder der Client- 
oder der Serverrolle entspricht. Da SAPs Endpunkte von 
mehreren Client/Server-Kommunikations verbindungen sein 
konnen, beinhalten sie eine entsprechende Anzahl an Ports, 
die der Verankerung der einzelnen Kommunikationsverbin- 
dungen dienen. SAPIFs machen SAP-Funktionalitat an Pro- 
zeB- und Frameklassen-Schnittstellen verfugbar, wobei ein 
SAP innerhalb einer ProzeBklasse Verbindungen zu mehre- 
ren SAPIFs haben kann. Dies bietet unter anderem die Mog- 
lichkeit, den SAPIFs entsprechende Namen zu geben, z. B. 
Ruckfahrlicht rechts, Ruckfahrlicht tinks, und damit den ge- 
zielten AnschluB weiterer Komponenten zu ermoglichen, 
obwohl die Funktionalitat von einem einzigen SAP erfullt 
wird. SAPIFs existieren nur wahrend des hierarchischen Sy- 
stementwurfs. Nach Auflosung der Hierarchie vor der In- 
stanzierung besteht keine Notwendigkeit mehr, diesem De- 
signelement eine Entsprechung in der Implementierung zu 
geben. 

Ports sind Ankerpunkte fiir bidirektionale Client/Server- 
-Kommunikations verbindungen zur Implementierungszeit. 
In dieser Eigenschaft stellen sie eine horizontale Kommuni- 
kationsschnittstelle auf Schicht 7 des ISO/OSI-Referenzmo- 
dells dar. An den Ports wird der eigentliche Kommunikati- 
onsmechanismus verankert, d. h. das Senden/Empfangen 
iiber externe physikalische Kommunikationsmedien, die In- 
terprozeBkommunikation und ein Eventmechanismus fur 
die effektive Kommunikation mit Firmware-Prozessen. Von 
einem SAP ausgehende Dienstanforderungen konnen folg- 
lich uber unterschiedliche Kommunikationsmechanismen 
weitergeleitet werden, je nachdem, mit welchem Kommuni- 
kationsmechanismus der jeweils gerade angesprochene Port 
hinterlegt ist. Analog zu den SAPIFs machen die PortTFs 
Port-Funktionalitat an Schnittstellen von nachfolgend be- 
schriebenen ProzeB- und Frameklassen verfugbar. Die Por- 
tlFs gehoren entweder zur Schnittstelle eines gerade entwor- 
fenen Frames oder zur Schnittstelle eines darin enthaltenen 
Frames oder Prozesses. 

Jede ProzeBklasse kann Datenelemente enthalten, welche 
sie im Sinne der Objektorientierung kapselt. Ein Datenele : 
ment hat einen Datentyp und kann durch einen Initialisie- 
rungswert vorbelegt werden. Es kann konstant oder variabel 
sein und ist dementsprechend in einem ROM oder RAM an- 
geordnet. Ferner werden die Datenelemente als private oder 
public klassifiziert. Die Initialisierung von private-Datenele- 
menten hat direkt beim Entwurf der ProzeBklasse zu erfol- 
gen, wahrend diejenige von public-Datenelementen auf ei- 
ner hierarchisch hoheren Designebene geschieht, wenn der 
entsprechende Kontext bekannt ist, in welchem die ProzeB- 
klasse verwendet wird. Die in der ProzeBinstanz gekapselten 
Datenelemente konnen nur von der ProzeBinstanz selbst ge- 
andert werden. 

Ein ProzeB im Rahmen der vorliegenden Client/Server- 
Architektur hat Schnittstellen, uber die er mit anderen Pro- 
zessen oder Frames verbunden werden kann. Er bietet Dien- 
ste an SAPIFs in Serverrolle an und nutzt Dienste von ande- 
ren Prozessoren an SAPIFs in Clientrolle. Das Verhalten ei- 
ner ProzeBklasse wird mittels endlicher Automaten be- 
schrieben. Jede ProzeBklasse kann als Summe dreier Kom- 
ponenten betrachtet werden, und zwar einer auBeren 
Schnittstelle, einer inneren Struktur und des Verhaltens. Fig. 
3 zeigt ein Beispiel des graphischen Erscheinungsbildes der 
inneren Struktur einer ProzeBklasse mit einer zugehorigen 
auBeren Schnittstelle. Das Verhalten einer ProzeBklasse als 
Reaktion auf eine eingehende Dienstanforderung gliedert 
sich in drei Teilaspekte, und zwar in die Anderung des inne- 
ren Zustands z der ProzeBklasse, d. h. eines endlichen Auto- 
maten FSM, der das Verhalten der ProzeBklasse reprasen- 
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tiert, in die Modifikationen an den gekapselten Datenele- 
menten (process data set) und die Ausfuhrung von Aktionen 
und gegebenenfalls Wechsel des Prozesses in Clientrolle, 
um Dienste von anderen Prozessen in Anspruch zu nehmen. 
Fig, 4 zeigt die Einbettung des endlichen Automaten, d. h. 5 
der Finite State Machine (FSM), in die ProzeBklasse. Wie 
aus Fig. 4 erkennbar, ktinnen eingehende Dienstanforderun- 
gen sowohl den x- Vektor des endlichen Automaten als auch 
den Process Data Set beeinflussen. Andert sich der x- Vektor, 
wird gemaB der Definition des endlichen Automaten ge- 10 
pruft, ob gegebenenfalls ein neuer Zustand erreicht wird und 
entsprechende Aktionen ausgefuhrt werden mils sen. Welche 
Aktionen ausgefuhrt werden, ergibt sich aus der Interpreta- 
tion des y-Vektors. Das Ausfuhren der Aktionen kann wei- 
tere Anderungen am Process Data Set und den Wechsel in 15 
die Clientrolle mit Anforderung von Diensten anderer Pro- 
zesse bedeuten. Weiter ist der Fig. 4 die charakteristische 
MaBnahme entnehmbar, die SAPs in Server- und Client- 
Modus auf Anwendungsebene zu implementieren. 

Um einen hierarchischen Softwareentwurf zu ermogli- 20 
chen, sind Frames als weitere Designelernente vorgesehen, 
die in ihrer intemen Struktur weitere Frames, Prozesse und 
notwendige Verbindungen kapseln konnen. Ein Frame hat 
wie ein ProzeB Schnittstellen, iiber die er mit anderen Pro- 
zessen oder Frames verbunden werden kann. Er bietet Dien- 25 
ste an SAPIFs in Serverrolle an und nutzt Dienste von ande- 
ren Prozessen an SAPIFs in Clientrolle. Prinzipiell konnen 
Frames zusatzlich mit einer Verhaltensbeschreibung verse- 
hen sein, was schlieBlich ein Zusammenf alien mit Prozessen 
bedeuten kann, so daB nur noch eines dieser beiden Desi- 30 
gnelemente auf Designebene benotigt wird. In diesem Fall 
rniissen fiir die Implementierung einer Anwendung fur alle 
ProzeBklassen auf hierarchisch unterster Designebene expli- 
zite Verhaltensbeschreibungen existieren, wahrend dies fur 
ProzeBklassen auf hierarchisch hoheren Ebenen optional ist, 35 
wobei dann deren Verhaltensbeschreibung mit derjenigen 
der in ihr enthaltenen ProzeBklassen niedrigerer Ebene zu- 
sammenpassen muB. 

Als wei teres Designelement sind Firmware-Prozesse vor- 
gesehen, mit denen Firmware charakteristischerweise als 40 
Prozesse beschrieben wird und die das Bindeglied zwischen 
einer jeweiligen Hardwarekomponente und genau einem zu- 
geordneten primaren Client oder Server bilden, Sie kommu- 
nizieren mit letzteren iiber Anwendungsprotokolle, wie sie 
auch zur Kommunikation zwischen den Prozessen verwen- 45 
det werden und besitzen demzufolge ebenfalls mindestens 
ein SAPIF. Im Unterschied zu Prozessen werden jedoch we- 
der innere Struktur, noch Verhalten von Firmware-Prozes- 
sen beschrieben, es konnen jedoch Datenelemente verwen- 
det werden. 50 

Fig. 5 zeigt am Beispiel der typischen fahrzeugspezi fi- 
schen Anwendungsfunktion "Ruckfahrscheinwerfer" bei- 
spielhaft die prinzipielle Vorgehensweise beim Funktions- 
entwurf gemaB dem vorliegenden Client/Server-Modell. 
Die graphische Darstellung von Fig. 5 zeigt hierzu ein auBe- 55 
res Frame 8, das zwei innere Frames 9, 10 und einen durch 
die Graphik seiner auBeren Schnittstelle 11 dargestellten 
ProzeB beinhaltet. Im ersten Schritt erfolgt die Identifikation 
der beteiligten Sensorik und Aktuatorik und damit die Fest- 
legung der primaren Clients und Server. Im gezeigten Bei- 60 
spiel wird die Funktion durch einen Schalter an der Schalt- 
kulisse eines Automatgetriebes aktiviert. Als Aktuator wird 
am Fahrzeugheck eine Gluhlampe eingeschaltet. Als End- 
punkte dieses Client/Server- Szenarios ergeben sich damit 
ein primarer Client zur Uberwachung des Riickfahrschalters 65 
und ein primarer Server zur Ansteuerung der digitalen Lam- 
penendstufe fiir den Ruckfahrscheinwerfer. Die eigentliche 
Funktionslogik befindet sich in einem Monitor, der in die- 



536 A 1 

8 

sem Fall lediglich den Schaltzustand mit der Zundklemmen- 
information verkniipft, so daB der Ruckfahrscheinwerfer bei 
ausgeschalteter Zilndung nicht eingeschaltet wird. 

Nachdem auf diese Weise die Struktur der Funktion fest- 
liegt, werden im nachsten Schritt die Protokolle zwischen 
den Clients und Servern definiert. Ein Protokoll besteht da- 
bei aus einer Anzahl von Diensten, die der Server dem 
Client anbietet. Im Beispieifall eines binaren Schalters ist 
zwischen primarem Client und Monitor nur die Information 
"Schalter eingeschaltet" oder "Schalter ausgeschaltet" aus- 
zutauschen. Bei der Aktuatorikansteuerung ergeben sich 
ebenfalls nur zwei Dienste, die der primare Server dem 
Funktions monitor anbieten muB, namlich "Endstufe ein- 
schalten" und "Endstufe ausschalten". 

Ein Blick in eine wahrend der Entwicklung entstandene 
Parts -Bibliothek kann zeigen, daB bereits ein Protokoll zur 
Ubertragung binarer Information exis tiert, das im Beispiei- 
fall sowohl fiir die Kommunikation zwischen primarem 
Client und Monitor als auch zwischen Monitor und prima- 
rem Server genutzt werden kann. Die entsprechenden Pro- 
zesse und Protokolle zur Einspeisung der Ziindklerhmenin- 
formation in dieses Funktionsszenario sind ebenfalls bereits 
in der Parts-Bib liothek enthalten, wobei in diesem Fall eine 
Kommunikationsverbindung zu demjenigen Client geniigt, 
der die aktuelle Ziindklemme an den Funktion smonitor wei- 
tergibt. 

Nachfolgend wird detaillierter auf die Implementierung 
der Client/Server-Architektur im Fahrzeug eingegangen. 
Eine grundlegende Komponente bildet das verwendete Be- 
triebssystem. Um die Portabilitat der Client/Server-Prozesse 
auf unterschiedliche Hardware-Plattformen sicherzustellen, 
ist auf den Steuergeraten eine Betriebssystemschicht reali- 
siert, welche die Abhangigkeiten der Software zur Hardware 
kapselt und eine abstrakte Programmierschnittstelle (Appli- 
cation Programming Interface; API) bereitstellt. Vorausset- 
zung fur den Einsatz der Client/Server-Architektur in einem 
Steuergerat ist ein echtzeitfahiges Multitasking-Betriebssy- 
stem. Beispielsweise kann das Echtzeit-Betriebssystem 
OSEK mit der Conformance-Class ECC1 gewahlt werden, 
da fur die Kommunikation der Event-Mechanismus notwen- 
dig ist. Die gegenseitige Unterbrechbarkeit einzelner Tksks, 
d. h. preemptives Scheduling, ist nicht zwingend erforder- 
lich. Fig. 6 zeigt die Struktur von Software-Modulen auf ei- 
nem Steuergerat mit der vorliegenden Client/Server-Archi- 
tektur sowie die Koexistenz zu konventionellen Applikatio- 
nen, wobei zusatzlich die Schichten des ISO/OSI-Referenz- 
modells zu Vergleichszwecken dargestellt sind. Aus Fig. 6 
ist ersichtlich, daB die Client/Server-Prozesse nicht direkt 
auf die Hardware zugreifen, sondern die Dienste des Be- 
triebssystems und der ORPC-Kommunikationsschicht und 
damit des OSEK COM nutzen, wobei die Kommunikations- 
beziehungen zwischen Client/Server-Prozessen mit gestri- 
chelten Linien wiedergegeben sind. Die gebogene Linie re- 
prasentiert eine CUent/Server-Kommunikation auf demsel- 
ben Gerat, wahrend die gerade Linie eine solche zwischen 
verschiedenen Geraten symbolisiert. Durch diese Struktur 
laBt sich eine Verschiebbarkeit der Client/Server-Anwen- 
dung zwischen verschiedenen Steuergeraten erreichen, die 
alle iiber entsprechende OSEK OS-, OSEK COM- und 
ORPC-OXDR-Implementierungen verfugen. In Fig. 7 ist 
die vorliegend getroffene MaBnahme veranschaulicht, die 
SAPs und die Ports fur das Zusammenspiel von Prozessen 
mittels Protokollen auf dem Niveau von Schicht 7 des ISO/ 
OSI-Referenzmodells zu implementieren. 

Wie gesagt, greifen die Client/Server- An wendungen auf 
Dienste einer Kommunikationsschicht zuriick. Dabei setzt 
die ORPC(OSEK-basierter Remote-Procedure-Call)- 
Schicht auf den Timer- und Event-Diensten des Betriebssy- 
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stems und den Kommunikationsroutinen der OSEK COM- 
Ebene auf. Die OSEK COM-Schicht stellt Kommunikati- 
onsroutinen bereit, uber die Tasks miteinander Daten aus- 
tauschen konnen. Die Kommunikation zweier Tasks erfolgt 
konfigurationsabhangig innerhalb desselben Adressraums 5 
oder zwischen verschiedenen Adressraumen iiber ein ent- 
sprechendes Transportmedium, wobei fur die Anwendung 
die tatsachliche Realisierung der Kommunikation verborgen 
bleibt. Die Kommunikationsebenen ORPC, OSEK COM, 
Geratetreiber und Hardware bilden die Schichten 6 bis 1 des 10 
ISO/OSI-Referenzmodells, wahrend Schicht 7, d. h. die An- 
wendungsschicht, direkt von der Client/Server- Anwendung 
bzw. den Anwendungsprotokollen ubernommen wird. 

Die ProzeBstruktur der Clients und Server beschreibt das 
Systemverhalten innerhalb der Architektur, womit aller- 15 
dings im Unterschied zu konventionellen Client/Server-Sy- 
stemen keine Interaktion mit der AuBenwelt modelliert 
wird. Diese Schnittstelle zur Umwelt wird in der vorliegen- 
den CSA durch zusatzliche Softwarebausteine, die soge- 
nannte Firmware, gebildet. Diese Firmware trennt die hard- 20 
wareabhangigen Teile der Funktion von der logischen Funk- 
tion des Client/Server-Systems. In ihr werden die Ein- und 
Ausgabeoperationen des Steuergerates behandelt. Norma- 
lerweise sind dies die Ansteuerung von I/O-Pins des Prozes- 
sors mit definiertem Timing. Die Firmware wird hard- 25 
warenah speziell fur das Steuergerat z. B. in Assembler oder 
C implementiert. Zur Client/Server-Umgebung stellt die 
Firmware eine Schnittstelle iiber Anwendungsprotokolle 
ahnlich denen von Client/Server- Prozessen bereit. Diejeni- 
gen Client- bzw. Server-Prozesse, die Auftrage aus der 30 
Firmware entgegennehmen oder diese beauftragen, werden 
als die primaren Clients bzw. Server bezeichnet, so daB 
diese primaren Prozesse direkt auf dem Steuergerat laufen, 
an dem auch die entsprechende Hardware angeschlossen ist. 
Uber diese Zwischenschicht ist auch eine Kommunikation 35 
zu anderen als den Client/Server-Prozessen denkbar, indem 
fiir die betreffende Applikation eine Schnittstelle zur Client/ 
Server-Umgebung in Form von entsprechender Firmware 
realisiert wird. 

Zwischen zwei Client/Server-Prozessen findet die Kom- 40 
munikation zum Datenaustausch iiber zwei asynchrone, uni- 
direktionale Punkt-zu-Punkt-Kanale statt. Sie basieren auf 
dem Prinzip des aus der Burokommunikations-Datenverar- 
beitung bekannten Remote-Procedure- Call (RPC), wobei 
dieser Mechanismus fiir den Anwendungsf all von Kraftf ahr- 45 
zeugen auf die dort vorhandenen, begrenzten Ressourcen 
angepafit und vereinfacht ist. So stehen z. B. keine Name- 
Services oder Security-Functions zur Verfugung, und es 
wird im allgemeinen auch keine sichere Kommunikation fiir 
den Nachrichtenaustausch vorausgesetzt. Der prinzipielle 50 
Ablauf des verwendeten OSEK-basierten Remote-Proce- 
dure-Call (ORPC) ist in Fig. 8 dargestellt. Bei einer Anfor- 
derung (Request) von einem Client- zu einem Server- ProzeB 
codiert eine Stub-Routine zunachst die Argumente in eine 
netzwerkneutrale, normalisierte Form. Der in der ORPC- 55 
Runtime-Bibliothek bereitgestellte Timed-RPC sorgt fiir die 
Ubertragung des Requests iiber das Netzwerk oder iiber 
Kommunikationsobjekte im selben Adressraum zum Server. 
Dort decodiert die entsprechende Server-Stub-Routine die 
Argumente, ruft mit diesen Parametern die Dienstimple- 60 
rnentierung auf und nimmt daraufhin die Ergebnisse entge- 
gen. Diese werden wieder in die normalisierte Darstellung 
umgewandelt und zum Client zuriickgesendet. Die Client- 
Stub-Routine sorgt fiir die Decodierung der Ergebnisse und 
gibt sie schlieBlich an den entsprechenden ProzeB zuriick. 65 

Fiir den Fall, daB bei der Ubertragung iiber ein Medium 
zwischen verschiedenen Adressraumen eine Nachricht ver- 
loren geht, ist im ORPC ein Mechanismus implementiert, 
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der Nachrichten wiederholen kann. Dazu ist fiir jede Nach- 
richt definiert, bis zu welchem Zeitpunkt nach dem Vers en- 
den des Requests die Antwort (Reply) erwartet wird. Kann 
diese Zeit nicht eingehalten werden, geht der Client davon 
aus, dafi entweder seine Request-Nachricht oder der Reply 
darauf verloren ging. Er sendet deshalb den Request erneut 
aus. Zusatzlich ist eine Maximalanzahl fur die Wiederholun- 
gen definiert, nach denen der Client mit einer entsprechen- 
den Fehlermeldung uber die Nichterfullung des Dienstes be- 
nachrichtigt wird. Mit diesem Mechanismus konnen nur 
idempotente Dienste realisiert werden, bei denen eine Wie- 
derholung eines bereits ausgefuhrten Dienstes keinen Ein- 
fluB auf das Gesamtergebnis oder den Systemzustand hat. 

Im Unterschied zu herkomrnlichen Implemenuerungen 
von RPC-Mechanismen fur die Biirokom munikation ist bei 
der vorliegenden CSA weitaus mehr Funktion alitat inner- 
halb der ORPC-Bibliotheksroutinen realisiert und standardi- 
siert. Gangige RPC-Implementierungen stellen der Anwen- 
dung lediglich die benotigten Kommunikationsfunktionen 
in Form einer Bibliothek zur Verfugung und ermoglichen 
dariiber hinaus nur die Generierung eines primitiven Geriists 
fur die eigentliche Server-Funktionalitat. Wenn dies, wie 
meist der Fall, nicht ausreicht, muB der Anwendungspro- 
grarnmierer den benotigten Server-Code selbst schreiben. 
Im Gegensatz dazu beinhaltet vorliegend die ORPC-Biblio- 
thek neben den Kommunikationsroutinen auch den vollstan- 
digen Server-Code. Dieser wird von alien Client- und Ser- 
ver-Prozessen abgearbeitet, d. h. er wird pro Steuergerat ge- 
nau einmal eingebunden. Dies erfullt in vorteilhafter Weise 
die Anforderungen nach minimalem Ressourcenbedarf und 
maximaler Wiederverwendungsfahigkeit. Dieser Server- 
Code wird von der Anwendung lediglich mit den jeweiligen 
prozeBspezifischen Daten aufgerufen und arbeitet diese 
nach einem festgelegten Verfahren ab. Das zugehorige Ser- 
ver-Zustandsdiagramm ist in Fig. 9 dargestellt. Nach Aufruf 
durch die Anwendung durchlauft der Server eine Initialisie- 
rungsphase, die sich in vier einzelne Phasen gliedert, wie im 
zugehorigen Initialisierungsdiagramm in Fig. 10 dargestellt. 
Zunachst werden die anwendungsspezifischen ProzeBdaten 
initialisiert, wozu aus dem Server-Code heraus eine anwen- 
dungsspezifische Funktion aufgerufen wird, welche der An- 
wendungsprogrammierer zur Verfugung stellt. Dann erfolgt 
die Initialisierung der Kommunikationskanale und der zuge- 
horigen Datenobjekte. Der Server-ProzeB ist nun empfangs- 
bereit und kann Anforderungen, d. h. Requests, von seinen 
Clients entgegennehmen. Der ProzeB geht daraufhin fur eine 
einstellbare Zeit in eine Wartestellung, bis ein Request emp- 
fangen wird oder die eingestellte Zeit abgelaufen ist. Diese 
MaBnahme dient der Lastverteilung beim Anlauf des Sy- 
stems bzw. dazu, unwichtigere Prozesse zu blockieren, bis 
sie tatsachlich benotigt werden. Zuletzt uberpruft der Server, 
ob er alle notwendigen Initialisierungsinformationen hat. Ist 
dies nicht der Fall, fordert er sie selbsttatig, d. h. ohne Mit- 
wirkung der Anwendung, bei den entsprechenden Clients 
an. Liegt nach einer einstellbaren Anzahl von Versuchen 
noch keine giiltige Initialisierung vor, verzweigt der Server 
in eine Notlauf-Funktion, ansonsten betritt der Server eine 
Schleife, in der er die eingegangenen Anforderungen nach- 
einander abarbeitet. 

Anstehende Requests werden dem Server-ProzeB iiber ei- 
nen vom Betriebssystem bereitgestellten Signalisierungs- 
mechanismus angezeigt. Anhand dieses Signals kann der 
Server zwischen verschiedenen Quellen unterscheiden und 
die entsprechende Bearbeitungsmethode anstoBen. Quelle 
dieser Signale konnen hierbei Nicht-CSA-Funktionen, wie 
Firmware, oder Betriebssysternfunktionen, wie Zeitgeber 
oder Interrupt-Mechanismen, oder andere CSA-Prozesse, 
wie Client-Prozesse, sein. Anhand des empfangenen Signals 
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wird vom Server-Code iiber eine Tabelle am entsprechenden 
SAP eine Stub-Routine aufgerufen. Die Stub-Routinen wer- 
den anhand der Informationen zu den Anwendungsprotokol- 
len automatisch generiert und rufen die vom Anwendungs- 
programmierer zur Verfugung gestellte Dienstimplementie- 
rung auf . Bei den Signalen wird zwischen sogenannten App- 
lication Events und den ORPC-Events unterschieden. Die 
Application Events werden zur Anbindung der Firmware 
und fur Betriebssystemfunktionen genutzt und direkt in ei- 
nen entsprechenden Aufruf umgesetzt. Die ORPC-Events 
sind durch den realisierten RPC-Mechanismus vorgegeben 
und dienen zur Anbindung anderer CSA-Prozesse. 

Fur die Realisierung des RPC kommen drei Varianten in 
Betracht, von denen der gebrauchlichste ein sogenannter 
synchroner RPC ist, der durch die Funktion Hmed-RPC der 
ORPC-Bibliothek realisiert ist. Fig. 11 zeigt das FluBdia- 
gramm dieser Funktion. Nach der Initialisierung der lokalen 
Daten der Funktion werden in einer Schleife die fur diese 
Methode konfigurierten Aufrufversuche (Attemps) abgear- 
beitet. Bei jedem Versuch wird hierzu zunachst ein Zeitge- 
ber mit dem entsprechenden Timeout- Wert geladen. Im An- 
schluB daran wird der Request versendet und auf den Aus- 
gang dieser Sende-Operation gewartet. War das Senden des 
Requests erfolgreich, betritt die Funktion eine Schleife, in 
der sie auf die Antwort, d. h. den Reply, wartet. Wird die 
Antwort nicht innerhalb der vorgegebenen Zeitspanne emp- 
.fangen, startet ein erneuter Ubertragungsversuch, sofern die 
Anzahl moglicher Versuche noch nicht tiberschritten ist. 
Lauft der Zeitgeber ab, bevor ein erfolgreicher Ausgang der 
Sendeoperation signalisiert wurde, wird ohne Warten auf 
Antwort der nachste Versuch gestartet. Auf Server-Seite 
wird durch den Empfang eines Requests eine entsprechende 
Server-Stub-Routine aufgerufen, welche ihrerseits die ei- 
gentliche Dienstimplementierung aufruft und nach deren 
Abarbeitung eine entsprechende Antwort an den Client-Pro- 
zeB zurucksendet. Abhangig vom Ausgang liefert die Funk- 
tion einen entsprechenden Fehlercode sowie im Erfolgsfall 
das zugehorige Ergebnis an die aufrufende Funktion, in die- 
sem Fall eine Client-Stub-Routine, zuriick. Innerhalb der 
Anwendung muB bei einem RPC zunachst dieser Fehler- 
code betrachtet werden, bevor im Erfolgsfall mit dem zu- 
riickgelieferten Ergebnis gearbeitet werden kann. Fur den 
Fall, daB ein RPC-Vorgang fehlschlagt, ist eine entspre- 
chende Fehlerbehandlung vom Anwendungsprogrammierer 
vorzusehen. 

Als weitere Variante kann ein sogenannter asynchroner 
RPC vorgesehen sein. Dieser entspricht einer Modification 
des synchronen RPC dahingehend, daB von der Server-Stub- 
Routine eine Antwort gesendet wird, bevor die eigentliche 
Dienstimplementierung aufgerufen wird. Der Client-ProzeB 
kann dadurch asynchron zu dem von ihm beauftragten Ser- 
ver-ProzeB weiterarbeiten. Der Server-ProzeB bzw. die auf- 
gerufene Stub-Routine bestatigt hierbei durch den Reply le- 
diglich den korrekten Empfang des entsprechenden Re- 
quests, nicht jedoch die erfolgte Bearbeitung. Infolgedessen 
ist diese Art des RPC nur fur Methoden zulassig, die kein 
Ergebnis, d. h. einen Ruckgabewert vom Typ "void", haben. 
Die Unterscheidung zwischen synchronem und asynchro- 
nem RPC erfolgt allein in der Server-Stub-Routine, wahrend 
die verwendeten CLient-Stub-Routinen in beiden Fallen 
identisch sind. Auch wird in beiden Fallen zur Kommunika- 
tion die Funktion Timed-RPC aufgerufen. 

Als dritte Variante kann der sogenannte Oneway-RPC 
vorgesehen sein, bei welchem im Gegensatz zu den beiden 
vorigen Mechanismen keine Antwort vom Server an den 
Client generiert wird. Dieser Mechanismus ist ebenfalls nur 
fiirFunktionen zulassig, die kein Ergebnis liefern. Im Unter- 
schied zu Timed-RPC realisiert die verwendete Kommuni- 



kationsfunktion Oneway-RPC keinen Hmeout-Retransmit- 
Mechanismus und wartet nicht auf eine Antwort des Ser- 
vers. Das zu dieser RPC- Variante gehorige FluBdiagramm 
ist in Fig. 12 dargestellt. 
5 Neben dem Aufruf der entsprechenden Kommunikations- 
funktion bzw. Dienstimplementierung sind die Client- und 
Server-Stub-Routinen auch fur das sogenannte Marshalling, 
d. h. die Konvertierung eines einfachen Datentyps aus einer 
prozessorspezifischen Darstellung in das zur Kommunika- 

10 tion verwendete normalisierte Format, und Unmarshalling, 
d. h. der Datenkonvertierung vom normalisierten Format in 
die prozessorabhangige Darstellung, der zugehorigen Para- 
meter und Ruckgabewerte verantwortlich. Dabei werden 
Byte- und Bit-Ordering und die Lange der Darstellung be- 

15 riicksichtigt. Die Client- und Server-Stub-Routinen werden 
anhand der Signatur einer Methode, d. h. unter Beriicksich- 
tigung von Anzahl, Reihenfolge und Typ der Parameter so- 
wie des Ruckgabewertes, automatisch generiert. Die Stub- 
Routinen enthalten die entsprechende Aufruf-Sequenz von 

20 Konvertierungsroutinen fur einfache Datentypen. Wahrend 
bei den herkommlichen Realisierungen der. Anwendungs- 
programmierer selbst Funktionen fur das Marshalling bzw. 
Unmarshalling bereitstellen. und an die Stub-Routine iiber- 
geben muB, wird diese Funktion ali tat hierdurch beim vorlie- 

25 genden System vollstandig innerhalb der Stubs gekapselt 
und bleibt der Anwendung verborgen. Dadurch ist der in der 
vorliegenden CSA realisierte RPC beziiglich der Schnitt- 
stelle fiir den Anwendungsprogrammierer transparent, d. h. 
durch die gewahlte Vorgehensweise ist die Schnittstelle der 

30 Anwendung zu den Stub-Routinen so gestaltet, daB diese 
exakt derjenigen bei einem lokalen Funktionsaufruf ent- 
spricht. Fiir jede Signatur existiert^genau ein Paar von Stub- 
Routinen, wobei Methoden mit gleicher Signatur dieselben 
Stub-Routinen verwenden. Dies ist von der methodenspezi- 

35 fischen Generierung von Stub-Routinen herkommlicher 
Realisierungen zu unterscheiden. Die vorliegende CSA 
macht im Unterschied zu herkommlichen Architekturen von 
der Moglichkeit einer (Wieder-)Verwendung von Stub-Rou- 
tinen durch mehrere Methoden Gebrauch. 

40 Eine Randbedingung fur die normalisierte Darstellung in 
einem Netzwerk ist, daB auf den eingesetzten Microcontrol- 
lern der Aufwand fur die Umsetzung moglichst gering ist. 
Anstelie herkommlicher Realisierungen einer External- 
Data-Representation wurde daher fiir das vorliegende Sy- 

45 stem eine eigenstandige normalisierte Darstellung in Form 
einer OXDR (OSEK-basierte externe Datenrepresentation) 
definiert. Konvertierungsroutinen fur einfache Datentypen 
werden in einer Bibliothek zur Verfugung gestellt. OXDR 
zeichnet sich durch eine Trennung von Marshalling- und 

50 Unmarshalling-Routinen aus, was selektives Einbinden der 
benotigten Module und somit minimalen ROM-Bedarf er- 
moglicht. AuBerdem konnen fiir die Datenkonvertierung 
Quell- und Zieldatenbereich identisch sein, was den RAM- 
Bedarf der Konvertierungsroutinen minimi ert. 

55 Fur die Protokollimplementierung erhalt jede Methode ei- 
nes Anwendungsprotokolls eine eindeutige, als Dienstnum- 
mer bezeichnete Nummer. Mit dieser identifiziert sowohl 
der Client den gewiinschten Dienst als auch der Server die 
dazugehorende Dienstimplementierung. In den Nachrichten 

60 sind in den Nutzdaten sowohl der Nachrichtentyp, d. h. Re- 
quest, Reply oder Error, als auch die Dienstnummer und die 
ubergebenen Daten kodiert. Fig. 13 zeigt eine Darstellung 
des so realisierten Protokolls. Dabei bedeuten Bit 7 ein Er- 
ror-Flag, Bit 6 Reply-Flag und die Bits 5 bis 0 die Service- 

65 ID zwischen 0 bis 63. Die Anfangsbits "00 ..." bedeuten ei- 
nen Request fur den Dienst mit der anschlieBenden Num- 
mer, die Anfangsbits "01 . . ." einen Reply auf den Dienst- 
aufruf mit der anschlieBenden Nummer und die Anfangsbits 
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"11. . einen Fehler bei der Verarbeitung des Dienstes mit 
der anschlieBenden Nummer. Mit Application-Data sind die 
beim Aufruf der Methode ubergebenen Daten bzw. die Ant- 
wort darauf bezeichnet. Der Client sendet also eine Nach- 
richt mit einer Dienstnummer an seinen Server, der anhand 5 
der geloschten Bits 6 und 7 und der Dienstnummer pruft, ob 
es sich um einen Request handelt und ob er diesen Dienst er- 
bringen kann. Nach der erfolgreichen Verarbeitung des 
Dienstes sendet der Server die Ergebnisse unter derselben 
Dienstnummer mit dem gesetzten Bit 6 an den Client zu- 10 
ruck. Dieser erkennt an der Dienstnummer, dem gesetzten 
Bit 6 und dem geloschten Bit 7, daB es sich um ein giiltiges 
Ergebnis zum aufgerufenen Dienst handelt. Falls der Server 
einen geforderten Dienst nicht erbringen kann, beantwortet 
er den Request mit einer Fehlernachricht, indem er die Bit 6 15 
und 7 setzt und in den Anwendungsdaten den entsprechen- 
den Fehler kodiert. 

Im Ergebnis steht somit fur das Steuerungssystem ein ob- 
jektorieritierter Ansatz zur Verfugung, bei der alle in der 
CSA verwendeten Prozesse eine oder mehrere definierte 20 
Schnittstellen in Form von SAPs bzw. SAPIFs haben, iiber 
die mit Ihnen mittels Anwendungsprotokollen kommuni- 
ziert wird. Die Prozesse konnen lokale Daten besitzen, die 
nur iiber die Anwendungsprotokolle rnodifiziert werden 
konnen, und sie besitzen einen inneren Zustand, da das Ver- 25 
halten eines solchen Prozesses iiber einen einfachen Auto- 
maten (FSM) festgelegt ist. Damit folgt der Entwurf mit der 
Client/Server-Methode den wesentlichen Paradigmen des 
objektorientierten Designs. Das Design der Anwendung er- 
folgt auf Klassenebene durch Aufbau von Kommunikations- 30 
beziehungen zwischen den ProzeBklassen. Zur Generie- 
rungszeit werden aus diesen kommunizierenden ProzeB- 
klassen die ProzeBinstanzen erzeugt und mit entsprechenden 
Daten vorbelegt, wobei auch Polymorphismus durch Uber- 
schreiben der Dienstimplementierungen an dieser Stelle 35 
moglich ist. Als hierarchische Strukturierungsmittel finden 
Frames Verwendung, die andere Frames oder ProzeBklas- 
sen, Firmware und Kommunikationsverbindungen enthalten 
konnen, sogenannte Construction of Parts. Aus diesen 
Frames kann dann nach der Bottomup-Designmethode, d. h. 40 
durch Construction from Parts, die Anwendung zusammen- 
gebaut werden. Ein einmal angelegtes, implementiertes und 
getestetes Frame laBt sich in beliebig vielen Anwendungen 
wiederverwenden, so daB eine erhebliche Effizienz- und Ef- 
fektivitatssteigerung gegenuber dem konventionellen Ent- 45 
wurf ermoglicht wird. Durch die vorliegend realisierte CSA 
ist eine hohe Rexibilitat auch im Bereich der Kraftfahrzeu- 
gelektronik gegeben, die eine baureiheniibergreifende Ver- 
wendung der Anwendungsfunktionen oder zumindest von 
Teilen derselben erlaubt. Wird beispielsweise bei einer 50 
neuen Baureihe eine Anwendungsfunktion nur hinsichtlich 
ihrer Funktionslogik, nicht aber ihrer zugehorigen Sensorik 
oder Aktuatorik verandert, reicht eine Modifizierung des 
entsprechenden Funktionsmonitors aus. Durch die vorlie- 
gende Strukturierung von Funktionen wird folglich auch die 55 
Wartungsfahigkeit verbessert. 

Der EntwicklungsprozeB wird formal durch ein Design- 
und Implementierungswerkzeug unterstiitzt, rnit dem der 
gesamte DesingprozeB und Teile des Implemenuerungspro- 
zesses unterstiitzt werden. Damit konnen in der Design- 60 
phase die ProzeBklassen rnit ihren Schnittstellen und Daten 
spezifiziert werden. Zusammen mit den entwickelten An- 
wendungsprotokollen lassen sie sich zu Frames kombinie- 
ren, die ihrerseits in anderen Frames genutzt werden kon- 
nen. Am SchluB des Design-Prozesses fur eine neue Funk- 65 
tion wird der Kontext festgelegt, in welchem die Frames an- 
gewendet werden, z. B. zur Festlegung der Frequenz und 
des Tastverhaltnisses im Fail der Blinkfunktion eines Fahr- 



zeugblinkgebers. Aus den mit Hilfe des Entwicklungswerk- 
zeugs entworfenen Funktionen wird eine Parts -Bibliothek 
aufgebaut. 

Wie die vorstehende Beschreibung eines Anwendungs- 
falls fur ein Kraftfahrzeug zeigt, bietet das erfindungsge- 
maBe Steuerungssystem mit der implementierten Client/ 
Server- Architektur erhebliche Vorteile. Der Entwicklungs- 
aufwand wird durch systematische Wiederverwendung und 
Anderungsfreundlichkeit so wie weitgehende Automatisie- 
rung vereinfacht, wozu eine klare Trennung zwischen logi- 
schem Entwurf einer Fahrzeugfunktion und deren physikali- 
scher Einbettung in die Steuergeratestruktur realisiert ist. 
AuBer Funktionsentwiirfen sind auch entsprechende Simu- 
lationsmodelle und implementierte Software-Module in 
gleicher Weise flexibel einsetzbar, was den Aufwand nicht 
nur in der Entwurfsphase, sondem auch in der Implementie- 
rungs- und in der Integrationsphase verringert. Durch die er- 
findungsgemaBe Systemauslegung ergibt sich ein groBer 
Freiheitsgrad beztiglich der Plazierung einzelner Funktio- 
nen auf den Steuergeraten im vernetzen Steuergeratever- 
bund. ... ... ..... 

Wenngleich die Erfindung im Detail anhand eines Kraft- 
fahrzeug-Steuerungssys terns erlautert wurde, versteht es 
sich, daB sie auch auf andere Arten von datenverarbeitungs- 
gestiitzten elektronischen S teuerungssystemen mit einem 
Steuergerateverbund aus verteilt angeordneten Steuergera- 
ten anwendbar ist. 

Patentanspruche 

1. Datenverarbeitungsgestiitztes elektronisches Steue- 
rungssystem, insbesondere fur ein Kraftfahrzeug, mit 

- einem Anwendungsfunktionen ausfuhrenden 
Steuergerateverbund mit rnehreren, verteilt ange- 
ordneten Steuergeraten (la, lb, lc) und einem 
diese verbindenden Datenubertragungsnetzwerk 
(2), dadurch gekennzeichnet, daB 

- die Anwendungsfunktionen in Form einer 
Client/Server- Architektur in dem Steuergerate- 
verbund implementiert sind. 

2. Steuerungssystem nach Anspruch 1, weiter dadurch 
gekennzeichnet, daB die Client/Server- Architektur fur 
eine jeweilige Anwendungsfunktion eine Client-Ebene 
(5), eine Server-Ebene (6) und eine zwischenliegenden 
Funktionsmonitorebene (7) beinhaltet, welche Dienst- 
anforderungen von der Client-Ebene und/oder von 
ubergeordneten Anwendungsfunktionen empfangt und 
unter Benutzung von Diensten der Server-Ebene und/ 
oder von untergeordneten Anwendungsfunktionen be- 
arbeitet. 

3. Steuerungssystem nach Anspruch 2, weiter dadurch 
gekennzeichnet, daB 

- die Client-Ebene (5) wenigstens einen primaren 
Client (5a) und einen zugehorigen Requestor (5b) 
en malt, wobei der Requestor ereignisauslosende 
Hardware-Einheiten und eine zugehorige Steuer- 
gerate-Firmware reprasentiert und der primare 
Client den Requestor verwaltet, Diensteanforde- 
rungen von ihm entgegennimmt und Auftrage an 
die Funktionsmonitorebene (7) ab setzt, und/oder 

- die Funktionsmonitorebene pro Anwendungs- 
funktion einen Funktionsmonitor (7a), der Dienst- 
anforderungen der Client-Ebene (5) entgegen- 
nimmt und bearbeitet, sowie diesem untergeord- 
nete Monitore (7b) zur Verwaltung von Teilfunk- 
tionen enthalt und/oder 

- die Server-Ebene (6) wenigstens einen prima- 
ren Server (6a) und einen zugehorigen Fulfiller 
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(6b) beinhaltet, wobei die Fulfiller ausfuhrende 
Hardware-Einheiten und zugehbrige Steuerge- 
rate-Firmware reprasentieren und der primare 
Server den Fulfiller verwaltet und mit der Ausfuh- 
rung von Diensten beauftragt sowie Dienstanfor- 5 
derungen von der Funktionsmonitorebene (7) ent- 
gegennimmt. 

4. Steuerungssystem nach einem der Anspriiche 1 bis 

3, weiter dadurch gekennzeichnet, daB als eine Gruppe 
von Designelementen fur den Funktionsentwurf der 10 
Client/Server-Architektur Service- Access-Points 
(SAPs) vorgesehen sind, die AnwendungsprozeB- 
Schnittstellen auf dem Niveau von Schicht 7 des ISO/ 
OSI-Referenzmodells bilden und je ein Protokoll in 
Client- und Serverrolle beinhalten. 15 

5. Steuerungssystem nach einem der Anspriiche 1 bis 

4, weiter dadurch gekennzeichnet, daB als eine Gruppe 
von Designelementen fur den Funktionsentwurf der 
Client/Server-Architektur Ports als horizontale Kom- 
munikationsschnittstellen auf Schicht 7 des ISO/OSI- 20 
Referenzmodells als Ankerpunkte fur die bidirektio- 
nale Chent/Server-Kommunikationsverbindung zur 
Implementierungszeit vorgesehen sind. 

6. Steuerungssystem nach einem der Anspriiche 1 bis 

5, weiter dadurch gekennzeichnet, daB als eine Gruppe 25 
von Designelementen fur den Funktionsentwurf der 
Client/Server-Architektur Prozesse in Form von Pro- 
zeBklassen vorgesehen sind, die eine auBere Schnitt- 
stelle, eine innere Struktur und ein Verhalten umfassen, 
welches Anderungen des internen Zu stands (z) der Pro- 30 
zeBklasse, Modiflkationen an gekapselten Datenele- 
menten und die Ausfuhrung von Aktionen beinhaltet. 

7. Steuerungssystem nach einem der Anspriiche 1 bis 

6, weiter dadurch gekennzeichnet, daB in den Steuerge- 
raten eine Betriebssystemschicht mit einem echtzeitfa- 35 
higen Multitasking-Betriebssystem implementiert ist 
und als Kommunikationsschicht eine solche vom Re- 
mote- Procedure-Call-Typ (RPC) verwendet ist, wobei 
die Client/Server-Prozesse auf die Dienste des Be- 
triebssystems und der Kommunikationsschicht ohne 40 
direkten Hardware- Zugriff zuriickgreifen. 

8. Steuerungssystem nach Anspruch 7, weiter dadurch 
gekennzeichnet, daB in einer RPC-Bibliothek ein voll- 
standiger Server-Code abgelegt ist, der pro Steuergerat 
genau einmal eingebunden ist und von alien Client- 45 
und Server-Prozessen abgearbeitet wird. 

9. Steuerungssystem nach Anspruch 7 oder 8, weiter 
dadurch gekennzeichnet, daB der RPC- Vorgang fur die 
Kommunikationsschicht als synchroner, asynchroner 
oder Oneway-RPC- Vorgang realisiert ist. 50 

10. Steuerungssystem nach einem der Anspriiche 7 bis 
9, weiter dadurch gekennzeichnet, daB das Nachrich- 
tenprotokoll Informationen iiber den Nachrichtentyp, 
eine Dienstnummer einer jeweiligen Methode eines 
Anwendungsprotokolls und die zu iibergebenden Da- 55 
ten enthalt. 
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